Add suggestion for relaxing static lifetime bounds on dyn trait impls in NLL #97284

b-naber · 2022-05-22T18:16:05Z

This PR introduces suggestions for relaxing static lifetime bounds on impls of dyn trait items for NLL similar to what is already available in lexical region diagnostics.

Fixes #95701

r? @estebank

b-naber · 2022-05-22T20:04:45Z

Weird that this compiled locally for me with the static_assert_size of 24.

Probably needs a perf-run.

jackh726 · 2022-05-22T23:46:02Z

I would have expected the NLL output of src/test/ui/suggestions/impl-on-dyn-trait-with-implicit-static-bound.rs to change. Did you bless with compare-mode=nll?

jackh726

Still need to look at this a bit more, but was just thinking if there was any way to unify these suggestions with the existing ones?

jackh726 · 2022-05-23T17:27:30Z

compiler/rustc_middle/src/ty/impls_ty.rs

-            ty::ReVar(..) => {
-                bug!("StableHasher: unexpected region {:?}", *self)
+            ty::ReVar(reg_vid) => {
+                reg_vid.hash_stable(hcx, hasher);


Why did this change?

Was hitting an ICE because ConstraintCategory is HashStable and we encounter ReVar in the substs that we added.

Can we add a delay_span_bug call here? We really don't want to accidentally produce a binary if it shouldn't.

Wouldn't we still ICE if we added that here (due to delay_span_bug being called, but no error having been found)?

Yes, but only if no other errors are emitted, which would only happen if a diagnostic isn't built. I'm assuming that ReVar is only being encountered due to diagnostic changes and not changes that would affect the final binary, right?

jackh726 · 2022-05-23T17:28:19Z

compiler/rustc_middle/src/mir/query.rs

-// Make sure this enum doesn't unintentionally grow
-rustc_data_structures::static_assert_size!(ConstraintCategory, 12);
-


Why remove the assert? (Are there problems when there is a lifetime?)

Because SubstsRef doesn't have a static size I think, at least I was hitting that assertion.

Eh that's nonsense, of course it must have a static size. I really don't know why I was hitting those assertions, but the first two CI runs failed because of that, didn't have that problem locally.

Two things: you might want to rebase on top of a recent master to see if that way you can replicate the issue locally, and you might want to turn the CallArgument variant to hold a Box<Option<(DefId, SubstsRef<'tcx>)>> to see if that keeps you under the 12 bytes size. Increasing the size of these types that are used a lot can cause compilation performance regressions that are really difficult to regain.

jackh726 · 2022-05-23T17:29:50Z

compiler/rustc_infer/src/infer/error_reporting/nice_region_error/util.rs

@@ -51,9 +52,19 @@ pub fn find_param_with_region<'tcx>(
    let hir_id = hir.local_def_id_to_hir_id(id.as_local()?);
    let body_id = hir.maybe_body_owned_by(hir_id)?;
    let body = hir.body(body_id);
+
+    // Don't perform this on closures


Because we can't call fn_sig on closures.

In the resulting ICE if you call fn_sig on closures, it tells you what you should call instead: substs.as_closure().sig()

I don't think it actually makes sense to look for closures here given the function's intention. This was previously never called on closures, it's just that the way we can call this we can still end up with a closure in this call and we need the HIR check to properly reject this if I remember correctly.

I suspect that this might have been what caused the output changes that used to point at async and closures (but don't know for sure and the output changes aren't too dramatic).

jackh726 · 2022-05-23T17:35:18Z

compiler/rustc_borrowck/src/diagnostics/region_errors.rs

+        if let Some((ident, self_ty)) =
+            self.get_impl_ident_and_self_ty_from_trait(instance.def_id(), &visitor.0)
+        {


Could use let else

bors · 2022-05-24T10:38:08Z

☔ The latest upstream changes (presumably #96098) made this pull request unmergeable. Please resolve the merge conflicts.

estebank · 2022-05-24T17:23:56Z

compiler/rustc_borrowck/src/type_check/mod.rs

+        let call_arg = if let TerminatorKind::Call { func, .. } = &term.kind {
+            let func_ty = func.ty(body, self.infcx.tcx);
+            if let ty::FnDef(fn_did, substs) = func_ty.kind() {
+                Some((*fn_did, *substs))
+            } else {
+                None
+            }
+        } else {
+            None
+        };
+        debug!(?call_arg);


I'm guessing the other cases that are not handled here are async blocks and closures, right?

Yes I believe so.

estebank · 2022-05-24T17:51:52Z

compiler/rustc_borrowck/src/diagnostics/region_errors.rs

@@ -256,6 +263,70 @@ impl<'a, 'tcx> MirBorrowckCtxt<'a, 'tcx> {
        outlives_suggestion.add_suggestion(self);
    }

+    fn get_impl_ident_and_self_ty_from_trait(


It feels to me like we might already have code doing this somewhere 🤔

We do already have that functionality in lexical region diagnostics (NiceRegionError), but can't directly use that struct in NLL (and at some point we will get rid of it anyway afaict).

estebank · 2022-05-24T17:53:39Z

compiler/rustc_borrowck/src/diagnostics/region_errors.rs

+            for span in &traits {
+                let mut multi_span: MultiSpan = vec![*span].into();
+                multi_span.push_span_label(
+                    *span,
+                    "this has an implicit `'static` lifetime requirement".to_string(),
+                );
+                multi_span.push_span_label(
+                    ident.span,
+                    "calling this method introduces the `impl`'s 'static` requirement".to_string(),
+                );
+                err.span_note(multi_span, "the used `impl` has a `'static` requirement");
+                err.span_suggestion_verbose(
+                    span.shrink_to_hi(),
+                    "consider relaxing the implicit `'static` requirement",
+                    " + '_".to_string(),
+                    Applicability::MaybeIncorrect,
+                );
+                suggested = true;
+            }


I also think that we might already have logic for this, but if it is not accessible for some reason, I'm not above a little duplication for a clear diagnostic improvement.

estebank · 2022-05-24T17:55:05Z

.../closure-requirements/propagate-approximated-shorter-to-static-comparing-against-free.stderr

+LL |       let cell = Cell::new(&a);
+   |                            ^^ borrowed value does not live long enough
 ...
-LL | }
-   | - `a` dropped here while still borrowed
+LL | /     foo(cell, |cell_a, cell_x| {
+LL | |         cell_x.set(cell_a.get()); // forces 'a: 'x, implies 'a = 'static -> borrow error
+LL | |     })
+   | |______- argument requires that `a` is borrowed for `'static`
+LL |   }
+   |   - `a` dropped here while still borrowed


I'm somewhat worried about the output changes here and in the async block in /issue-72312.nll.stderr. It also seems like we should also special case their output if we could 🤔

This case actually seems like an improvement, we "just" need to figure out how to point at the inside of the closure :-/

It's kind of weird that this does not point to the start of the closure anymore. Personally I don't really think this makes the diagnostic any less helpful (since the point where the drop happen implies that anyway), but I can try to investigate if you find this important.

Would you mind to do so as a follow up? In this case in particular it is an improvement, but I'm not so sure about the other ones.

b-naber · 2022-05-25T21:48:39Z

@estebank Addressed your review. We use the Ty of the function directly now, instead of its DefId + substs, which does, however, still increase the size of ConstraintCategory by 4 bytes unfortunately.

…nstraintCategory

bors · 2022-05-26T22:10:38Z

📌 Commit 3c6c8d5 has been approved by estebank

bors · 2022-05-27T00:30:31Z

⌛ Testing commit 3c6c8d5 with merge 2a0c6ac83a9a29409d6db4d5f2d77457261993ce...

bors · 2022-05-27T01:01:10Z

💔 Test failed - checks-actions

rust-log-analyzer · 2022-05-27T01:05:25Z

The job test-various failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)


---- [ui] src/test/ui/invalid/invalid-llvm-passes.rs stdout ----
diff of stderr:

1 error: failed to run LLVM passes: unknown pass name 'unknown-pass'
+ thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
+   left: `LLVMing`,
+   left: `LLVMing`,
+  right: `Codegenning`', $COMPILER_DIR/rustc_codegen_ssa/src/back/write.rs:1471:21
+    0:     0x7fc5b0a9818d - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::ha6d42905ae8495e1
+    1:     0x7fc5b0af401c - core::fmt::write::he61c0a83568f530b
+    1:     0x7fc5b0af401c - core::fmt::write::he61c0a83568f530b
+    2:     0x7fc5b0a89921 - std::io::Write::write_fmt::hf12b960ff621bcd4
+    3:     0x7fc5b0a9ae75 - std::panicking::default_hook::{{closure}}::h1e32ea7d973577fd
+    4:     0x7fc5b0a9ab96 - std::panicking::default_hook::h0f733119b617cb2f
+    5:     0x7fc5b1872b19 - rustc_driver[956148c2c5381e18]::DEFAULT_HOOK::{closure#0}::{closure#0}
Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-musl
+    6:     0x7fc5b0a9b54a - std::panicking::rust_panic_with_hook::h10f2619916c4d7f0
+    7:     0x7fc5b0a9b387 - std::panicking::begin_panic_handler::{{closure}}::hc10db1e63006eff3
+    8:     0x7fc5b0a98644 - std::sys_common::backtrace::__rust_end_short_backtrace::h8514961be8260c05
+    9:     0x7fc5b0a9b0b9 - rust_begin_unwind
+   10:     0x7fc5b0a60413 - core::panicking::panic_fmt::h5cbf0cc0bcd5482c
+   11:     0x7fc5b0af0dc8 - core::panicking::assert_failed_inner::h0cd989a79f6863cc
+   12:     0x7fc5b15e43bb - core[b767cee21b229350]::panicking::assert_failed::<rustc_codegen_ssa[b548771e8a124ff8]::back::write::MainThreadWorkerState, rustc_codegen_ssa[b548771e8a124ff8]::back::write::MainThreadWorkerState>
+   13:     0x7fc5b1ada995 - std[8a7407eec8ab889b]::sys_common::backtrace::__rust_begin_short_backtrace::<<rustc_codegen_llvm[6af3a2890704cafe]::LlvmCodegenBackend as rustc_codegen_ssa[b548771e8a124ff8]::traits::backend::ExtraBackendMethods>::spawn_thread<rustc_codegen_ssa[b548771e8a124ff8]::back::write::start_executing_work<rustc_codegen_llvm[6af3a2890704cafe]::LlvmCodegenBackend>::{closure#4}, core[b767cee21b229350]::result::Result<rustc_codegen_ssa[b548771e8a124ff8]::back::write::CompiledModules, ()>>::{closure#0}, core[b767cee21b229350]::result::Result<rustc_codegen_ssa[b548771e8a124ff8]::back::write::CompiledModules, ()>>
+   14:     0x7fc5b1b4cfe4 - <<std[8a7407eec8ab889b]::thread::Builder>::spawn_unchecked_<<rustc_codegen_llvm[6af3a2890704cafe]::LlvmCodegenBackend as rustc_codegen_ssa[b548771e8a124ff8]::traits::backend::ExtraBackendMethods>::spawn_thread<rustc_codegen_ssa[b548771e8a124ff8]::back::write::start_executing_work<rustc_codegen_llvm[6af3a2890704cafe]::LlvmCodegenBackend>::{closure#4}, core[b767cee21b229350]::result::Result<rustc_codegen_ssa[b548771e8a124ff8]::back::write::CompiledModules, ()>>::{closure#0}, core[b767cee21b229350]::result::Result<rustc_codegen_ssa[b548771e8a124ff8]::back::write::CompiledModules, ()>>::{closure#1} as core[b767cee21b229350]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
+   15:     0x7fc5b0aa5463 - std::sys::unix::thread::Thread::new::thread_start::h6cfee43c7d984174
+   16:     0x7fc5b07e4609 - start_thread
+   17:     0x7fc5b0926133 - clone
+   18:                0x0 - <unknown>
+ error: internal compiler error: unexpected panic
+ 
+ note: the compiler unexpectedly panicked. this is a bug.
+ 
+ 
+ note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
+ 
+ note: rustc 1.63.0-nightly (2a0c6ac83 2022-05-27) running on x86_64-unknown-linux-gnu
+ 
+ note: compiler flags: -Z threads=1 -C codegen-units=1 -Z ui-testing -Z deduplicate-diagnostics=no -C prefer-dynamic -C rpath -C debuginfo=0 -C linker=x86_64-linux-musl-gcc -C passes=unknown-pass -Z new-llvm-pass-manager=yes
+ query stack during panic:
+ end of query stack
3 error: aborting due to previous error
4 
---
To only update this specific test, also pass `--test-args invalid/invalid-llvm-passes.rs`

error: 1 errors occurred comparing output.
status: exit status: 1
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/invalid/invalid-llvm-passes.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-musl" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/invalid/invalid-llvm-passes" "-A" "unused" "-Crpath" "-O" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-musl/native/rust-test-helpers" "-Clinker=x86_64-linux-musl-gcc" "-Cpasses=unknown-pass" "-Z" "new-llvm-pass-manager=yes" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/invalid/invalid-llvm-passes/auxiliary"
stdout: none
--- stderr -------------------------------
error: failed to run LLVM passes: unknown pass name 'unknown-pass'
thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
  left: `LLVMing`,
  left: `LLVMing`,
 right: `Codegenning`', /checkout/compiler/rustc_codegen_ssa/src/back/write.rs:1471:21
   0:     0x7fc5b0a9818d - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::ha6d42905ae8495e1
   1:     0x7fc5b0af401c - core::fmt::write::he61c0a83568f530b
   1:     0x7fc5b0af401c - core::fmt::write::he61c0a83568f530b
   2:     0x7fc5b0a89921 - std::io::Write::write_fmt::hf12b960ff621bcd4
   3:     0x7fc5b0a9ae75 - std::panicking::default_hook::{{closure}}::h1e32ea7d973577fd
   4:     0x7fc5b0a9ab96 - std::panicking::default_hook::h0f733119b617cb2f
   5:     0x7fc5b1872b19 - rustc_driver[956148c2c5381e18]::DEFAULT_HOOK::{closure#0}::{closure#0}
   6:     0x7fc5b0a9b54a - std::panicking::rust_panic_with_hook::h10f2619916c4d7f0
   7:     0x7fc5b0a9b387 - std::panicking::begin_panic_handler::{{closure}}::hc10db1e63006eff3
   8:     0x7fc5b0a98644 - std::sys_common::backtrace::__rust_end_short_backtrace::h8514961be8260c05
   9:     0x7fc5b0a9b0b9 - rust_begin_unwind
  10:     0x7fc5b0a60413 - core::panicking::panic_fmt::h5cbf0cc0bcd5482c
  11:     0x7fc5b0af0dc8 - core::panicking::assert_failed_inner::h0cd989a79f6863cc
  12:     0x7fc5b15e43bb - core[b767cee21b229350]::panicking::assert_failed::<rustc_codegen_ssa[b548771e8a124ff8]::back::write::MainThreadWorkerState, rustc_codegen_ssa[b548771e8a124ff8]::back::write::MainThreadWorkerState>
  13:     0x7fc5b1ada995 - std[8a7407eec8ab889b]::sys_common::backtrace::__rust_begin_short_backtrace::<<rustc_codegen_llvm[6af3a2890704cafe]::LlvmCodegenBackend as rustc_codegen_ssa[b548771e8a124ff8]::traits::backend::ExtraBackendMethods>::spawn_thread<rustc_codegen_ssa[b548771e8a124ff8]::back::write::start_executing_work<rustc_codegen_llvm[6af3a2890704cafe]::LlvmCodegenBackend>::{closure#4}, core[b767cee21b229350]::result::Result<rustc_codegen_ssa[b548771e8a124ff8]::back::write::CompiledModules, ()>>::{closure#0}, core[b767cee21b229350]::result::Result<rustc_codegen_ssa[b548771e8a124ff8]::back::write::CompiledModules, ()>>
  14:     0x7fc5b1b4cfe4 - <<std[8a7407eec8ab889b]::thread::Builder>::spawn_unchecked_<<rustc_codegen_llvm[6af3a2890704cafe]::LlvmCodegenBackend as rustc_codegen_ssa[b548771e8a124ff8]::traits::backend::ExtraBackendMethods>::spawn_thread<rustc_codegen_ssa[b548771e8a124ff8]::back::write::start_executing_work<rustc_codegen_llvm[6af3a2890704cafe]::LlvmCodegenBackend>::{closure#4}, core[b767cee21b229350]::result::Result<rustc_codegen_ssa[b548771e8a124ff8]::back::write::CompiledModules, ()>>::{closure#0}, core[b767cee21b229350]::result::Result<rustc_codegen_ssa[b548771e8a124ff8]::back::write::CompiledModules, ()>>::{closure#1} as core[b767cee21b229350]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
  15:     0x7fc5b0aa5463 - std::sys::unix::thread::Thread::new::thread_start::h6cfee43c7d984174
  16:     0x7fc5b07e4609 - start_thread
  17:     0x7fc5b0926133 - clone
  18:                0x0 - <unknown>
error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.


note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.63.0-nightly (2a0c6ac83 2022-05-27) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z threads=1 -C codegen-units=1 -Z ui-testing -Z deduplicate-diagnostics=no -C prefer-dynamic -C rpath -C debuginfo=0 -C linker=x86_64-linux-musl-gcc -C passes=unknown-pass -Z new-llvm-pass-manager=yes
query stack during panic:
end of query stack
error: aborting due to previous error
------------------------------------------

estebank · 2022-05-27T01:26:51Z

compiler/rustc_middle/src/ty/impls_ty.rs

-            ty::ReVar(..) => {
-                bug!("StableHasher: unexpected region {:?}", *self)
+            ty::ReVar(reg) => {
+                reg.hash_stable(hcx, hasher);


I wonder if the LLVM failure is due to this. As a refresher, what are the failures when you keep the bug!?

Don't think it's related to that. ReVar is HashStable, we just previously had the bug! call in there, because it wasn't used when hashing Region afaict. I just got the output of the message in the bug statement.

I'm sort of leaning towards thinking that this failure is spurious. The test is in the ui tests and passed on all other platforms and the code changes in this PR don't touch anything that should cause different behaviour on different platforms.

jackh726 · 2022-05-27T15:16:48Z

@bors retry maybe spurious?

bors · 2022-05-27T21:59:02Z

⌛ Testing commit 3c6c8d5 with merge 6c557271b8989188a4d0dbb93ad2a7fb1fbe5626...

bors · 2022-05-27T23:17:13Z

💔 Test failed - checks-actions

rust-log-analyzer · 2022-05-27T23:35:14Z

The job dist-x86_64-apple-alt failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

jackh726 · 2022-05-28T02:36:21Z

@bors retry spurious network error

bors · 2022-05-28T04:04:32Z

⌛ Testing commit 3c6c8d5 with merge ed76b77...

bors · 2022-05-28T06:45:09Z

☀️ Test successful - checks-actions
Approved by: estebank
Pushing ed76b77 to master...

rust-timer · 2022-05-28T08:03:50Z

Finished benchmarking commit (ed76b77): comparison url.

Instruction count

Primary benchmarks: 🎉 relevant improvement found
Secondary benchmarks: 🎉 relevant improvements found

	mean¹	max	count²
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	-0.2%	-0.2%	1
Improvements 🎉 (secondary)	-5.3%	-5.9%	6
All 😿🎉 (primary)	-0.2%	-0.2%	1

Max RSS (memory usage)

Results

Primary benchmarks: mixed results
Secondary benchmarks: mixed results

	mean¹	max	count²
Regressions 😿 (primary)	3.1%	4.0%	2
Regressions 😿 (secondary)	1.9%	2.4%	5
Improvements 🎉 (primary)	-4.3%	-4.3%	1
Improvements 🎉 (secondary)	-2.2%	-2.2%	1
All 😿🎉 (primary)	0.6%	-4.3%	3

Cycles

Results

Primary benchmarks: mixed results
Secondary benchmarks: 🎉 relevant improvements found

	mean¹	max	count²
Regressions 😿 (primary)	2.6%	2.6%	1
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	-2.3%	-2.3%	1
Improvements 🎉 (secondary)	-3.5%	-4.0%	6
All 😿🎉 (primary)	0.2%	2.6%	2

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

the arithmetic mean of the percent change ↩ ↩² ↩³
number of relevant changes ↩ ↩² ↩³

pnkfelix · 2022-05-31T21:09:08Z

Visiting for weekly performance triage.

This managed to improve performance on various variants of the wg-grammar secondary benchmark, probably because it restructured the CallArgument and that had fallout that ended up being positive overall (despite our intuition being that it would hurt performance due to the increase in size)? Is that correct? (Update: @estebank confirmed that understanding.)
It might be nice to confirm that hypothesis independently (by isolating just that structural change and confirming that it has a similar effect on performance here) ...
... but, the improvements are essentially isolated to just the secondary wg-grammar benchmark, so its not really worth too much digging, except if we think it might reveal other structural changes we should make elsewhere.

rust-highfive assigned estebank May 22, 2022

rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label May 22, 2022

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 22, 2022

This comment has been minimized.

Sign in to view

b-naber force-pushed the constraint-dyn-impl-suggestion branch from 50e9b6d to b70c418 Compare May 22, 2022 19:35

This comment has been minimized.

Sign in to view

b-naber force-pushed the constraint-dyn-impl-suggestion branch from b70c418 to c1c94a0 Compare May 22, 2022 20:04

b-naber force-pushed the constraint-dyn-impl-suggestion branch from 60aac63 to 1fda1fb Compare May 23, 2022 07:52

This comment has been minimized.

Sign in to view

b-naber force-pushed the constraint-dyn-impl-suggestion branch from 1fda1fb to 81e0e09 Compare May 23, 2022 16:20

jackh726 requested changes May 23, 2022

View reviewed changes

estebank reviewed May 24, 2022

View reviewed changes

b-naber added 5 commits May 25, 2022 18:13

add def_id and substs to ConstraintCategory::CallArgument

99fa572

make TraitObject visitors public

c1072d2

suggest constraining dyn trait in impl in NLL

5f65331

update tests

ca9d725

bless existing test with compare-mode=nll and remove test

99fa123

b-naber force-pushed the constraint-dyn-impl-suggestion branch 2 times, most recently from e04af21 to 5422fea Compare May 25, 2022 21:35

This comment has been minimized.

Sign in to view

b-naber force-pushed the constraint-dyn-impl-suggestion branch from 5422fea to d3be764 Compare May 25, 2022 21:46

This comment has been minimized.

Sign in to view

rebase, use Ty in CallArgument and re-insert static_assert_size on Co…

3c6c8d5

…nstraintCategory

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 26, 2022

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 27, 2022

estebank reviewed May 27, 2022

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 27, 2022

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 27, 2022

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 28, 2022

bors added the merged-by-bors This PR was explicitly merged by bors. label May 28, 2022

bors merged commit ed76b77 into rust-lang:master May 28, 2022

rustbot added this to the 1.63.0 milestone May 28, 2022

bors mentioned this pull request May 28, 2022

Remove migrate borrowck mode #95565

Merged

		// Make sure this enum doesn't unintentionally grow
		rustc_data_structures::static_assert_size!(ConstraintCategory, 12);

Add suggestion for relaxing static lifetime bounds on dyn trait impls in NLL #97284

Add suggestion for relaxing static lifetime bounds on dyn trait impls in NLL #97284

Conversation

b-naber commented May 22, 2022

This comment has been minimized.

This comment has been minimized.

b-naber commented May 22, 2022 • edited Loading

jackh726 commented May 22, 2022

This comment has been minimized.

jackh726 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented May 24, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment has been minimized.

b-naber commented May 25, 2022 • edited Loading

This comment has been minimized.

bors commented May 26, 2022

bors commented May 27, 2022

bors commented May 27, 2022

rust-log-analyzer commented May 27, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jackh726 commented May 27, 2022

bors commented May 27, 2022

bors commented May 27, 2022

rust-log-analyzer commented May 27, 2022

jackh726 commented May 28, 2022

bors commented May 28, 2022

bors commented May 28, 2022

rust-timer commented May 28, 2022

Footnotes

pnkfelix commented May 31, 2022 • edited Loading

b-naber commented May 22, 2022 •

edited

Loading

b-naber commented May 25, 2022 •

edited

Loading

pnkfelix commented May 31, 2022 •

edited

Loading